Amendment to the Claims: 



Please cancel claims 9, 11, 16, 35, and 37 without prejudice. 





1. (Currently amended) A method for processing receiving tradiiig partner transactions 
comprising: 

receiving at least one incoming transaction from at least one sending trading partner^ 
wherein receiving at least one incoming transaction from at/least one sending trading 
partner comprises receiving at least incoming transaction from at least one sending 
trading partner through an industry clearinghouse system^ 



translating at least one incoming transaction from a first data format to a second data 
format , wherein the first data format comprises a dat^ format of an industry clearinghouse 
system ; 

reading additional information from an adminis(tration system in data conomunication 
with a computer system, wherein the additional information is read in response to 
receiving at least one incoming transaction from the at least one sending trading partner, 
and wherein the additional information is ideiuified by at least one business rule; 

generating at least one outgoing transaciion in response to reading the additional 
information from the adnfiinistration systeni; and 

sending at least one outgoing transaction to at least one receiving trading partner. 



2. (Previously amended) The method of claim 1, wherein at least one business rule comprises 
one or more keywords. 



3. (Previously amended) The method of claim 1, wherein at least one business rule comprises 
one or more logical operators. 

4. (Previously amended) The method of claim 1, wherein at least one business rule comprises a 
string of at least one keyword and at least one operator, and wherein at least one business rule is 
entered into a computer system by a user via a user interface. 

5. (Previously amended) The method of claim 1, wherein at least one outgoing transaction 
comprises the additional information read from the administration system. 

6. (Previously amended) The method of claim 1, wherein the reading additional information 
from the administration system in response to receiving at least one incoming transaction from 
the at least one sending trading partner further comprises: extracting the additional information 
from the administration system according to search criteria. 

7. (Original) The method of claim 6, wherein the search criteria comprise one or more 
keywords. 

8. (Previously amended) The method of claim 1, further comprising: queuing at least one 
outgoing transaction in response to generating at least one outgoing transaction. 

9. (Cancelled) 

10. (Previously amended) The method of claim 1, wherein sending at least one outgoing 
transaction to at least one receiving trading partner further comprises sending at least one 
outgoing transaction to at least one receiving trading partner through an industry clearinghouse 
system. 

11. (Cancelled) 
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12. (Previously amended) The method of claim 1, wherein at least one incoming transaction is 
an insurance-related transaction. 



13. (Currently amended) A system comprising: / 
a CPU; / 

a database coupled to the CPU; / 

an administration system coupled to the CPU; / 

a memory coupled to the CPU, wherein the memory stores one or more computer 
programs executable by the CPU; wherein thexomputer programs are executable to: 

store a trading relationship between trading partners of a transaction, wherein the 
trading relationship is stored in the database, wherein at least one trading partner 
is a sending trading partner an^at least one trading partner is a receiving trading 
partner; / 

receive at least one incoming transaction from the at least one sending trading 
partne r, wherein at lea/t one incoming transaction is received from at least one 
sending trading partpfer through an industry clearinghouse system ; 

translate at leasyone incoming transaction from a first data format to a second 
data format , wnerein the first data format comprises a data format of an industry 

P se system : 
nal information from the administration system in response to 
least one incoming transaction from at least one sending trading 
jrein the additional information is identified by at least one business 
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generate at least one outgoing transaction in response to reading the additional 
information from the administration system; 




send at least one outgoing transaction to at least one receiving trading partner, 
wherein at least one receiving trading partner is identified in the trading 
relationship. ' 



14. (Previously amended) The system of claim 13, wherein at least one business rule comprises 
a string of at least one keyword and at least one operator, and wherein at least one business rule 
is entered into a computer system by a user via a user interface. 

15. (Previously amended) The system of claim 13, wherein at least one business rule is defined 
by a user through a user interface. 

16. (Cancelled) 

17. (Previously amended) The system of claim 13, wherein at least one incoming transaction is 
an insurance-related transaction. 

18. (Currently amended) A carrier medium, which stores program instructions, wherein the 
program instructions are executable by a computer system to implement the method of: 

receiving at least one incoming transaction/from at least one sending trading partner^ 
wherein receiving at least one incoming transaction from at least one sending trading 
partner comprises receiving at least incoming transaction from at least one sending 
trading partner through an industrv clgaringhouse svstem : 
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translating at least one incoming transaction from a first data format to a second data 
format , wherein the first data format comprises a dgfta format of an industry clearinghouse 
system ; / 

reading additional information from an administration system in response to receiving the 
incoming transaction from the at least one sending trading partner, wherein the additional 
information is identified by at least one business rule; 

generating at least one outgoing transaction m response to reading the additional 
information from the administration systenu 

sending at least one outgoing transaction to at least one receiving trading partner. 

19. (Previously amended) The carrier medium of claim 18, wherein at least one business rule 
comprises one or more keywords. 

20. (Previously amended) The carrier medium of claim 18, wherein at least one business rule 
comprises one or more logical operators. 

21. (Previously amended) The carrier medium of claim 18, wherein at least one business rule 
comprises a string of at least one keyword and at least one operator, and wherein at least one 
business rule is entered into the computer system by a user via a user interface. 

22. (Previously amended) The carrier medium of claim 18, wherein at least one business rule is 
stored in a database. 

23. (Previously amended) The carrier medium of claim 18, wherein the administration system 
from which additional information is read is specified by a map, wherein the map comprises a 
relationship between at least one outgoing transaction and a source for the additional 
information. 
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24. (Original) The carrier medium of claim 23, wherein the map is specified by a user through a 
user interface. 

25. (Previously amended) The carrier medium of claim 23, wherein the program instructions are 
further executable by the computer system to implement generating the map, wherein generating 
the map comprises: 

selecting one or more source fields, wherein each source field corresponds to the source 
for the additional information; 

selecting a destination field, wherein each destination field corresponds to at least one 
outgoing transaction. 

26. (Original) The carrier medium of claim 25, wherein a value of the destination field is a sum 
of respective values of the one or more selected source fields. 

27. (Original) The carrier medium of claim 25, wherein the program instructions are further 
executable by the computer system to implement generating a value of the destination field as a 
function of the one or more source fields. 

28. (Previously amended) The carrier medium of claim 18, wherein at least one outgoing 
transaction comprises the additional information read from the administration system. 

29. (Previously amended) The carrier medium of claim 18, wherein the program instructions are 
further executable by the computer system to implement storing a schedule in memory, wherein 
the schedule relates to at least one incoming transaction, and wherein the schedule comprises a 
predetermined time for receiving at least one incoming transaction from the at least one sending 
trading partner. 

30. (Previously amended) The carrier medium of claim 18, wherein the program instructions are 
further executable by the computer system to implement storing a schedule in memory, wherein 
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the schedule relates to at least one incoming transaction, and wherein the schedule comprises a 
predetermined time for reading the additional information from the administration system. 

31. (Previously amended) The carrier medium of claim 18, wherein the program instructions are 
further executable by the computer system to implement storing a schedule in memory, wherein 
the schedule relates to at least one outgoing transaction, and wherein the schedule comprises a 
predetermined time for sending at least one outgoing transaction to the at least one receiving 
trading partner. 

32. (Previously amended) The carrier medium of claim 18, wherein reading additional 
information from the administration system in response to receiving at least one incoming 
transaction from at least one sending trading partner further comprises extracting the additional 
information from the administration system according to search criteria. 

33. (Original) The carrier medium of claim 32, wherein the search criteria comprise one or more 
keywords. 

34. (Previously amended) The carrier medium of claim 18, wherein the program instructions are 
further executable by the computer system to implement queuing at least one outgoing 
transaction in response to generating at least one outgoing transaction. 

35. (Cancelled) 

36. (Previously amended) The carrier medium of claim 18, wherein at least one outgoing 
transaction is sent to the at least one receiving trading partner through an industry clearinghouse. 

37. (Cancelled) 

38. (Previously amended) The carrier medium of claim 18, wherein at least one incoming 
transaction is an insurance-related transaction. 
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39. (Previously amended) The carrier medium of claim 18, wherein at least one outgoing 
transaction is an insurance-related transaction. 

40. (Previously amended) The carrier medium of claim 18, wherein at least one outgoing 
transaction is an annuity asset pricing transaction. 

41. (Previously amended) The carrier medium of claim 18, wherein at least one outgoing 
transaction is a positions and valuation focused refresh transaction. 

42. (Previously amended) The carrier medium of claim 18, wherein at least one outgoing 
transaction is a positions and valuation full refresh transaction. 

43. (Previously amended) The carrier medium of claim 18, wherein at least one outgoing 
transaction is an insurance pricing transaction. 

44. (Previously amended) The carrier medium of claim 18, wherein at least one outgoing 
transaction is a conmiission settlement transaction. 

45. (Previously amended) The carrier medium of claim 18, wherein at least one sending trading 
partner is the receiving trading partner. 

46. (Original) The carrier medium of claim 18, wherein the carrier medium is a memory 
medium. 



. (Currently amended) A carrier mediumyWhich stores program instructions, wherein the 
rogram instructions are executable by a computer system to implement the method of: 
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storing a trading relationship between trading partners of a transaction, wherein at least 
one trading partner is a sending trading partner and at le^t one trading partner is a 
receiving trading partner; / 
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receiving at least one incoming transaction from at least one sending trading partner^ 
wherein receiving at least one incoming transaction from at least one sending trading 
partner comprises receiving at least incoming transacnon from at least one sending 
trading partner through an industry clearinghouse system ; 

translating at least one incoming transaction from i first data format to a second data 
format , wherein the first data format comprises a ^ata format of an industry clearinghouse 
system ; 



reading additional information from an administration system in response to receiving the 
incoming transaction from the at least one senning trading partner, wherein the additional 
information obtained is identified by at least one business rule; 

generating at least one outgoing transactioiyin response to reading additional information 
from the administration system; 

sending at least one outgoing transaction io the at least one receiving trading partner, 
wherein the at least one receiving trading partner is identified in the trading relatio nship. 

48. (Previously amended) The carrier medium of claim 47, wherein at least one business rule 
comprises a string of at least one keyword and at least one operator, and wherein at least one 
business rule is entered into the computer system by a user via a user interface. 



49. (Previously amended) The carrier medium of claim 47, wherein at least one business rule is 
stored in a database. 
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50. (Previously amended) The carrier medium of claim 47, wherein at least one outgoing 
transaction is an insurance-related transaction. 

51. (Original) The carrier medium of claim 47, wherein the carrier medium is a memory 
medium. 

52. (Previously amended) The method of claim 1, wherein at least one business rule comprises a 
receiving trading partner identifier. 

53. (Previously amended) The method of claim 1, wherein at least one business rule comprises 
an administration system identifier. 

54. (Previously amended) The method of claim 1, wherein at least one business rule comprises a 
transaction identifier. 

55. (Previously amended) The method of claim 1, wherein at least one business rule comprises a 
transaction status. 

56. (Previously amended) The method of claim 1, wherein at least one business rule comprises a 
sending trading partner identifier. 

57. (Previously amended) The method of claim 1, wherein at least one business rule is entered 
into a database. 

58. (Previously amended) The carrier medium of claim 18, wherein at least one business rule 
comprises a receiving trading partner identifier. 

59. (Previously amended) The carrier medium of claim 18, wherein at least one business rule 
comprises an administration system identifier. 
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60. (Previously amended) The carrier medium of claim 18, wherein at least one business rule 
comprises a transaction identifier. 

61. (Previously amended) The carrier medium of claim 18, wherein at least one business rule 
comprises a transaction status. 

62. (Previously amended) The carrier medium of claim 18, wherein at least one business rule 
comprises a sending trading partner identifier. 

63. (New) The method of claim 1, wherein the industry clearinghouse system comprises an 
insurance industry clearinghouse system. / 

64. (New) The method of claim 1, wherein the industry clearinghouse system comprises an 
insurance annuity clearinghouse system. / 

65. (New) The system of claim 13, wherein the/industry clearinghouse system comprises an 
insurance industry clearinghouse system. / I) 

66. (New) The system of claim 13, wherei/ the imklstry clearinghouse system comprises an 
insurance annuity clearinghouse system, v/^^x^ 

67. (New) The carrier medium of paim 18, wherein the industry clearinghouse system 
comprises an insurance industry clearinghouse system. 

68. (New) The carrier medium /of claim 18, wherein the industry clearinghouse system 
comprises an insurance annuity cleraringhouse system. 

69. (New) The carrier medium of claim 47, wherein the industry clearinghouse system 
comprises an insurance industry clearinghouse system. 
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70. (New) The carrier medium of /giafm 47, wherein the industry clearinghouse system 
comprises an insurance annuity clearingfiousa^ystem. 
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Response to Office Action Mailed November 21. 2002 



A. Claims in the Case 

Claims 1-62 have been rejected. Claims 1-70 are pending. Claims 1, 11, 13, 18, 37, and 
47 have been amended. Claims 9, 1 1, 16, 35, and 37 have been cancelled. Claims 63-70 are 
new. 

B. The Claims Are Not Obvious Over Borghesi in View of Richards Under 35 U.S.C> § 
103(a) 

The Examiner has rejected claims 1-62 as being obvious over U.S. Patent Application 
No. 5,950,169 to Borghesi et al. (hereinafter "Borghesi") in view of Official Notice taken by the 
Examiner under 35 U.S.C. § 103(a). Examiner cited U.S. Patent Application No. 6,408,303 to 
Richards (hereinafter "Richards") to support the Official Notice. Applicant respectfully 
disagrees with these rejections. 

In order to reject a claim as obvious, the Examiner has the burden of establishing a prima 
/ad^ case of obviousness. In re Warner et al., 379 F.2d 1011, 154U.S.P.Q. 173, 177-178 
(C.C.P.A. 1967). To estabhsh a prima facie obviousness of a claimed invention, all the claim 
limitations must be taught or suggested by the prior art. In re Royka, 490 F.2d 981, 180 U.S.P.Q. 
580 (C.C.P.A. 1974), MPEP § 2143.03. 

If an independent claim is nonobvious under 35 U.S.C. § 103, then any claim depending 
therefrom is nonobvious. In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), MPEP § 
2143.03. 

The Examiner states: 
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Borghesi does not teach translating at least one incoming transaction from 
a first data format to a second data format. Official notice is taken that translating 
incoming data from a first data format to a second data format is well known in 
the art.... Therefore, it would have been obvious to one with ordinary skill in the 
art at the time the invention was made to combine the feature above with 
Borghesi 's for the purpose of time-consuming because the incoming data need not 
be re-entered to another data format compatible with the trading partner's internal 
data processing system. 

Applicant respectfully traverses the assertion that translating at least one incoming 
transaction from a first data format to a second data format was old and well-known in the art at 
the time of the invention. Applicant believes MPEP 2144.03 will apply. Pursuant to MPEP 
2144.03, Applicant respectfully requests the Examiner to provide support for his assertion either 
by an affidavit or by references brought to the Applicant's attention. Otherwise, Applicants 
request this rejection be removed. See, e.g., MPEP 2143.01. 

Applicant submits that the combination of Borghesi and the Official Notice given by the 
Examiner does not teach or suggest all the features of independent claims 1, 13, 18 and 47. 

Amended claims 1,18, and 47 describe a combination of features including but not 
limited to: "wherein receiving at least one incoming transaction from at least one sending 
trading partner comprises receiving at least incoming transaction from at least one sending 
trading partner through an industry clearinghouse system" and "translating at least one incoming 
transaction from a first data format to a second data format, wherein the first data format 
comprises a data format of an industry clearinghouse system." Amended claim 13 describes a 
combination of features including but not limited to: "^ wherein at least one incoming 
transaction is received from at least one sending trading partner through an industry 
clearinghouse system" and "translate at least one incoming transaction from a first data format to 
a second data format, wherein the first data format comprises a data format of an industry 
clearinghouse system." 
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Support for the above-mentioned features is found in Applicant's Specification. 
Applicant's Specification states: 

An incoming transaction may be received from the at least one sending 
partner as identified in a trading relationship. In one embodiment, the incoming 
transaction may be received through the Annuity Processing Service of the 
NSCC. 

(Specification, page 3, lines 28-30) 
Applicant's Specification further states in support of the above-mentioned amendment: 

The trading partners and computer system for transaction processing are 
configured to exchange transaction data electronically with one another through 
the industry clearinghouse. The industry clearinghouse may require transaction 
data to be exchanged in a particular data format. For example, in one 
embodiment the industry clearinghouse is the Annuity Processing System (APS) 
or Insurance Processing System (IPS) of the National Securities Clearing 
Corporation (NSCC). In one embodiment, the computer system for transaction 
processing includes industry adapters to convert or translate incoming transaction 
data from NSCC data formats or other standard data formats and outgoing 
transaction data to NSCC data formats or other standard data formats. As used 
herein, an 'industry adapter' includes a computer program, utility, driver, or 
interface which translates or converts data to or from a standardized data format. 
(Specification, page 8, line 24 to page 9, line 8) 

The Examiner states: "Richards (US 6,408,303) discloses translating at least one 
incoming transaction from a first data format to a second data format (column 2, line 60- 
column 3, line 67)." 

Richards states: 



A system and method for building a trading partner profile for use with 
commercial translator software is disclosed. ... The commercial translator 
software uses the trading partner profile to complete the translation of the 
incoming file to a format for use by business or other apphcations. 
(Richards, Abstract) 

Richards also states: 
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The present invention automates the process of building a trading partner profile 
for use with conimercial translator software. The present invention is particularly 
well suited for use by businesses that have many trading partners submitting few 
transactions. The present invention is cost-effective in any environment that relies 
on trading partner profiles for processing of EDI-based transactions because the 
process of building a trading partner profile is fully automated. Information 
regarding each trading partner for a business is stored in a trading partner profiles 
database so that a translator in accordance with the trading partner profile may 
process incoming transactions. Each trading partner profile is comprised of a 
plurality of fields or parameters that the translator uses in processing files or 
transactions from a particular trading partner. The present invention therefore 
automatically determines the values of the fields or parameters that the translator 
uses for processing. Although the structure of a trading partner profile varies 
based on the translator used by the business, some basic information is conmion 
to virtually all translators. 

The present invention is comprised of several software components that 
operate in accordance with data stored in files, lists, tables, databases, etc. to 
provide the features and functionality described herein. Although the present 
invention is described in terms of multiple software components and information 
stores, it is understood that the features and functionality of the present invention 
could be provided in accordance with fewer or more components and/or 
information stores. A Determine File Type component examines an inbound or 
incoming file to determine its type. A Build Trading Partner Profile component 
extracts information from the incoming file and a list of file type/map associations 
to build a trading partner profile that is stored in a trading partner profile database. 
A Perform Translation component then extracts information from the trading 
partner profile database to complete the translation of the incoming file to a 
format for use by business or other appUcations. 

To use the present invention, a business that would like to accept or 
receive files from various trading partners defines a list of file types that it is 
willing to accept. The files may be EDI standard or non-EDI files. As long as the 
business and trading partner have agreed on a file format, any type of file may be 
processed by the present invention. For each file type that the organization has 
determined it will accept or receive, the name of a map for the file type and an 
instruction for calling the translator with the map is further specified in the list. 
The file type, map name, and instruction information is preferably stored in a 
table or database. Information in an incoming file drives the process of building 
the trading partner profile so that it does not have to be created manually. The 
incoming file is examined to determine its type. After the file type is determined, 
a trading partner identifier is extracted from the incoming file. The trading partner 
identifier, preferably, identifies the trading partner profile within the trading 
partner profile database. If a profile for the trading partner exists, it is used by the 



18 



translator to complete the translation process. If a profile for the trading partner 
does not exist, it is built automatically as follows. 

First, an entry in the trading partner profile database is created based on 
the trading partner identifier extracted or selected from the incoming file. 
Information regarding terminators and separators for the specific conmiercial 
translator in use by the business is added to the profile. The terminator and 
separator information typically is found in the incoming file and is located or 
selected based on the known or pre-defined structure of the file. Next, a map 
direction that identifies whether the transaction is inbound or outbound is located 
or selected and added to the profile. Also stored in the trading partner profile 
database is a production or test indicator that may be determined from the 
incoming file. Following completion of the trading partner profile, the translator 
completes translation of the incoming file based on information contained in the 
trading partner profile. 

(Richards, column 2, line 60 - column 3, line 67) 
Richards further states: 



Referring to FIG. 1, a business that would like to accept or receive files 
from various trading partners defines a list of file types that it is willing to accept. 
For each file type that the organization has determined it will accept or receive, 
the name of a map for the file type and an instruction for calling the translator 
with the map is further specified in the list. 
(Richards, column 4, lines 10-15) 

Richards appears to teach building trading partner profiles for "a business that would like 
to accept and receive files from various trading partners" without the use of an intermediary. 
Richards appear to teach that the trading partner profiles enable a trading partner to translate files 
from the various trading partners. Amended claims 1,18, and 47 describe the features of 
including but not limited to "translating at least one incoming transaction from a first data format 
to a second data format, wherein the first data format comprises a data format of an industry 
clearinghouse system." Amended claim 13 describes the features of including but not limited to 
"translate at least one incoming transaction from a first data format to a second data format, 
wherein the first data format comprises a data format of an industry clearinghouse system." 

An industry clearinghouse refers to an entity that acts as an intermediary (e.g., APS 
clearinghouse) between trading partners that provides "a flexible system for the transmission of 
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information to and from trading partners such as insurance carriers, broker/dealers, agents, 
banks, and other organizations." (Specification, page 2, lines 1-3) An industry clearinghouse, 
such as APS, includes multiple "trading partners who are members." (Specification, page 2, 
lines 4-5). Richards does not appear to teach or suggest translating or receiving files from an 
industry clearinghouse system. 

B. The Claims Are Not Obvious Over Borghesi in View of Berman Under 35 U,S.C> § 
103(a) 

The Examiner has rejected claims 1-62 as being obvious over U.S. Patent Application 
No. 5,950,169 to Borghesi et al. in view of Official Notice taken by the Examiner under 35 
U.S.C. § 103(a). Examiner cited U.S. Patent Application No. 5,995,939 to Berman et al. 
(hereinafter "Berman") to support the Official Notice. Applicant respectfully disagrees with 
these rejections. 

The Examiner states: "Berman et al. (US 5,995,939) discloses translating at least one 
incoming transaction from a first data format to a second data format (colunm 8, line57-colunm 
9, line 23 and column 14, lines 35-45). 

Berman states: 

The automated networked service request and fulfillment system described 
herein also includes a "universal interface" software component 290, typically 
stored on the client system's data storage medium 24 (identified in FIG. 1), which 
provides a solution to the problems encountered as a result of the myriad of 
database record formats presently in use in professional offices. In the past, 
converting these existing, "legacy" database records into the record and database 
format used by a new office management software package required hours of 
manual data re-entering. The universal interface program provides an automated 
method of importing the legacy data records, converting them into the record 
format used and needed by the client software 28, and storing the converted 
records into a new database. This process normally need only be performed once, 
when the automated networked service request and fulfillment system is first 
incorporated into an office. Once all the legacy records have been converted and 
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stored into a new database, all new records are entered directly into the new 
database. 

(Berman, column 8, line 57 to column 9, line 3) 

Berman appears to teach translating or converting existing database records from one 
format to another on the same storage medium. Berman does not appear to teach or suggest 
translating files received from a sending trading partner or an industrial clearinghouse system. 
Therefore, Berman does not appear to teach or suggest translating at least one incoming 
transaction from a first data format to a second data format, wherein the first data format 
comprises a data format of an industry clearinghouse system. 

C. The Claims Are Not Obvious Over Borghesi in View of Spurgeon Under 35 U,S,C> § 
103(a) 

The Examiner has rejected claims 1-62 as being obvious over U.S. Patent Application 
No. 5,950,169 to Borghesi in view of Official Notice taken by the Examiner under 35 U.S.C. § 
103(a). Examiner cited U.S. Patent AppHcation No. 6,088,677 to Spurgeon (hereinafter 
"Spurgeon") to support the Official Notice. Applicant respectfully disagrees with these 
rejections. 

The Examiner states: "Spurgeon (US 6,088,677) discloses translating at least one 
incoming transaction from a first data format to a second data format." 

Spurgeon states: 

An information-exchange system is provided for controlling the exchange 
of business and clinical information between an insurer and multiple health care 
providers. The system includes an information-exchange computer that is 
connected over a local area network to an insurer computer using a proprietary 
database and over the Internet to health-care provider computers using open 
database-compliant databases. The information-exchange computer receives 
subscriber insurance data from the insurance computer database, translates the 
insurance data into an exchange database, and pushes the subscriber insurance 
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data out over the Internet to the computer operated by the health-care provider 
assigned to each subscriber. 
(Spurgeon, Abstract) 

Spurgeon appears to teach a system for exchanging information between an insurer and 
multiple healthcare providers. Spurgeon appears to teach a system that translates data from an 
insurer for use by multiple healthcare providers. Spurgeon does not appear to teach or suggest 
the use of an industry clearinghouse system. Spurgeon does not appear to teach or suggest at 
least the combination of features including but not limited to translating at least one incoming 
transaction from a first data format to a second data format, wherein the first data format 
comprises a data format of an industry clearinghouse system. 

D. The Claims Are Not Obvious Over Borghesi in View of Bover Under 35 U.S.C, § 
103(a) 

The Examiner has rejected claims 1-62 as being obvious over U.S. Patent Application 
No. 5,950,169 to Borghesi in view of Official Notice taken by the Examiner under 35 U.S.C. § 
103(a). Examiner cited U.S. Patent Application No. 6,208,973 to Boyer et al. (hereinafter 
"Boyer") to support the Official Notice. Applicant respectfully disagrees with these rejections. 

The Examiner states: "Boyer et al. (US 6,208,973) discloses translating at least one 
incoming transaction from a first data format to a second data format (colunm 1, lines 49-55)." 

Boyer states: 

In conventional automated third party payor systems in the healthcare 
industry, the claim for payment is generated by the administrative staff of the 
healthcare provider or healthcare maintenance organization and transmitted 
electronically to a clearinghouse that accepts the electronic transmission, edits and 
processes the transmission, and reroutes and sends the claim electronically to the 
appropriate third party payors. Li the health insurance industry, intermediaries 
receive claims from healthcare providers or other claimants, edit the claims data 
for validity and accuracy, translate the data from a given format into one 
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acceptable to the intended third party payor (e.g., insurance company), and 
forward the processed claim to the appropriate third party payor. 
(Boyer, column 1, lines 42-55) 

Boyer appears to teach a clearinghouse that receives a claim for payment from a 
healthcare provider, processes the claim, and translates the claim to a format appropriate for a 
third party payor. Boyer appears to teach a payor (i.e., a receiving trading partner) receiving an 
incoming transaction from a healthcare provider (i.e., a sending trading partner) through a 
clearinghouse. Boyer does not appear to teach the features of amended claims 1, 13, 18, and 47 
including but not limited to a receiving trading partner (e.g., a payor) "translating" (or 
"translate") "at least one incoming transaction from a first data format to a second data format, 
wherein the first data format comprises a data format of an industry clearinghouse system. 
Boyer teaches that the clearinghouse translates an incoming transaction (claim for payment) to 
the data format of the payor (receiving trading partner), so that the payor does not have to 
translate the transaction. 

Thus, the combination of Borghesi and Boyer does not appear to teach or suggest such 
combination of features of amended claims 1,18, and 46 including but not limited to the features 
of translating at least one incoming transaction from a first data format to a second data format, 
wherein the first data format comprises a data format of an industry clearinghouse system. In 
addition, the combination of Borghesi and Boyer does not appear to teach or suggest such 
combination of features of amended claim 13 including but not limited to the features of translate 
at least one incoming transaction from a first data format to a second data format, wherein the 
first data format comprises a data format of an industry clearinghouse system. 

E. Summarv 

Based on the above. Applicant submits that all of the claims are now in condition for 
allowance. Favorable reconsideration is respectfully requested. 
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